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Abstract 

Ground-based controllers can remain in continuous communication with spacecraft in low Earth orbit 
(LEO) with near-instantaneous communication speeds. This permits near real-time control of all of the 
core spacecraft systems by ground personnel. However, as NASA missions move beyond LEO, light-time 
communication delay issues, such as time lag and low bandwidth, will prohibit this type of operation. As 
missions become more distant, autonomous control of manned spacecraft will be required. The focus of 
this paper is the power subsystem. For present missions, controllers on the ground develop a complete 
schedule of power usage for all spacecraft components. This paper presents work currently underway at 
NASA to develop an architecture for an autonomous spacecraft, and focuses on the development of 
communication between the Mission Manager and the Autonomous Power Controller. These two systems 
must work together in order to plan future load use and respond to unanticipated plan deviations. Using a 
nominal spacecraft architecture and prototype versions of these two key components, a number of 
simulations are run under a variety of operational conditions, enabling development of content and format 
of the messages necessary to achieve the desired goals. The goals include negotiation of a load schedule 
that meets the global requirements (contained in the Mission Manager) and local power system 
requirements (contained in the Autonomous Power Controller), and communication of off-plan 
disturbances that arise while executing a negotiated plan. The message content is developed in two steps: 
first, a set of rapid-prototyping “paper” simulations are preformed; then the resultant optimized messages 
are codified for computer communication for use in automated testing. 

1.0 Introduction 

As manned spacecraft travel further from Earth, light-time communication delays will make the 
present ground-based mission control unworkable (Ref. 1). To enable distant missions, NASA has begun 
investigating architectures that will provide autonomous control of the spacecraft (Refs. 1 and 2). 
Currently, controllers develop a complete schedule for all spacecraft components (e.g., Electric Power 
System (EPS), Thermal Management, Communications, Environmental Control and Life Support 
Systems); much of this schedule is created by humans on the ground running software tools to analyze the 
subsystem for which they are responsible (Refs. 3 to 5). 

For the case of the electric power system onboard the International Space Station, the planning 
process involves teams at three different locations (Ref. 5). In addition to solving the planning problem, 
controllers on the ground respond to disturbances and faults that may occur in each of the subsystems. In 
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order to enable autonomous operation, all of this functionality must be implemented onboard. 
Unfortunately, it is neither realistic nor useful to require that the flight crew gain expert knowledge of all 
vehicle subsystems. Thus, the control software must be capable of responding to these situations through 
an autonomous or semi-autonomous decision-making process. 

This paper presents an early attempt to formalize and automate the processes of planning the power 
system load scheduling, and responding to disturbances in the plan or plan constraints, using on-vehicle 
computation resources. The main focus is on development of a communication scheme between two key 
spacecraft components: the Mission Manager (MM) and the Autonomous Power Controller (APC). 

Section 2.0 provides a high-level overview of the proposed autonomous spacecraft control 
architecture, the MM, the APC, and the test power system. Section 3.0 describes the process used for 
development of the communication format for the messages between the MM and the APC. Conclusions 
are presented in Section 4.0. 

2.0 Autonomous Spacecraft Control Architecture 

This section briefly describes the Autonomous Spacecraft Control Architecture discussed more fully 
in Reference 6. Two key subsystems, the MM and the APC, are also described, as is the power system 
under test. 

A potential autonomous spacecraft controller architecture is shown in Figure 1 (Ref. 6). In this 
architecture, the MM is responsible for the high level control functions (e.g., planning), while each of the 
subsystems features an autonomous controller (e.g., Autonomous Power Controller, Autonomous 
Thermal Controller, etc.) which interfaces with the respective subsystem hardware. As previously 
mentioned, this work focuses on developing the communication protocol between the MM and the APC, 
both highlighted in green. 


Telemetry 

Command 



Figure 1. — Autonomous spacecraft controller architecture. 
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2.1 Mission Manager Overview 


The spacecraft MM is responsible for coordinating the various subsystems, as well as managing crew 
time to achieve mission objectives. From the power system perspective, the most important global issue is 
load scheduling (creating a timeline of when loads are in use and their associated priority). However, 
because the vehicle-level optimal planning problem is highly complex, a key goal of this system is to 
limit the amount of subsystem detail the MM is required to know. Thus the spacecraft’s MM must work 
in concert with the APC (where the EPS subsystem detail is located) to develop a load schedule based on 
mission priorities, as well as inputs that it has received from the other autonomous subsystems. Due to the 
fact that the MM has a global perspective of vehicle status, it is able to diagnose and provide 
recommendations regarding faults that affect more than one subsystem (Ref. 7). 

2.2 Autonomous Power Controller Overview 

While the vehicle MM is responsible for strategic planning and coordination of all subsystems, the 
autonomous subsystem controllers such as the APC are responsible for operating the subsystem in the 
manner most consistent with the strategic plan. The APC directly interfaces with the Electrical Power 
System (EPS) hardware, as shown in Figure 1, and has detailed knowledge of the electrical power system. 
This detailed knowledge (e.g., available power, energy storage capacity, operating modes, etc.) allows the 
APC to work in tandem with the MM to solve the relevant vehicle planning problem (i.e., develop a 
feasible a load schedule). The APC also manages local control issues, and reports them to the spacecraft 
MM. 


2.3 Example Power System 

The communication developed in this paper is not tied to any specific vehicle power system. It can be 
applied to any power system type. Typically, such a power system will contain four main components: 
power generation, energy storage, a switchable network, and electrical loads. 

In order to conduct the load planning exercises performed in this paper, it was necessary to define 
vehicle power system architecture. The selected architecture includes solar arrays for power generation, 
batteries for energy storage and a switchable network architecture as described in Reference 7. Also, a set 
of 30 notional loads was defined, and their corresponding power consumption was arbitrarily constructed. 
An eclipse/insolation period of 30/60 min was assumed. 

One key objective of this type of controller is to minimize lower level knowledge required by higher 
level systems. However, note that some key information must be held common by both the MM and the 
APC. In this case, this common information includes the list of loads, the load numbers, and the power 
usage for each load. 

3.0 Communication Development 

This section includes an overview of the communication required between the MM and the APC, 
describes the rapid-prototype “paper” simulations performed, provides details of the test cases run, and 
provides the resultant automated communications message format. 
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3.1 Communications Overview 


The purpose of this message development exercise is to define a communication protocol between the 
MM and the APC, which can be automated and allows the two subsystems to work in tandem to achieve 
the desired goals. The goals of this communication exchange are to enable the two systems to: 

1. Work together to negotiate a feasible load schedule that maximizes the mission objectives achieved 
by the vehicle. 

2. Communicate, and then adapt to, any unexpected deviation from the agreed-upon plan. 

To achieve the goals above, two separate classes of communication have been defined: Planning 
Communications and Asynchronous Communications. 

Planning Communications are used to negotiate a load schedule. They are always initiated by the 
MM, and are used to negotiate a load schedule which is feasible and with appropriate priority (defined by 
the MM), based on the power system availability (defined by the APC). The negotiated load schedule 
must meet global requirements at the MM level, while utilizing local detailed system information (e.g., 
line capacity, state of charge, network configuration, etc.) at the APC level to ensure that no power 
system constraints are violated. The resulting load schedule lists the state and priority of each load in the 
system at discrete time intervals over a defined planning window. This schedule may then be executed 
upon request by the vehicle MM. 

Asynchronous Communications are used when a disturbance arises while executing a previously 
negotiated plan. They are always initiated by the APC outside of the typical planning cycle. These 
messages may be sent in case of component failures, system failures, or any other unexpected change in a 
system operating state or constraint. For the purposes of this document, only disturbances to the load plan 
and unanticipated changes in power availability are considered; component and system failures will be 
addressed in future work. 

A high-level overview of the tasks which must be accomplished during Planning and Asynchronous 
Communications is listed below. 

3.1.1 Planning Communications Cycle 

1. Initiate Planning : At the initialization of the planning process, the MM informs the APC of the 
proposed planning period start time, end time, and time step. 

2. Define Power Constraints : The APC then uses the above data as well as its knowledge of the system 
status to compute the nominal and peak power availability at each time step of the planning window, 
and the peak energy available during the planning window. The APC sends this information, along 
with any load power constraints, back to the MM. 

3. Define Load Schedule : The MM then uses this power, energy, and constraint information, along with 
crew status and information from other subsystems, to develop a proposed vehicle plan. One 
component of this plan is a schedule of load power utilization and priority, for each load in the 
system, which is then communicated to the APC. 

4. Determine Feasibility : The APC performs power flow calculations and contingency analyses to 
determine the feasibility of the proposed load plan at each time step of the planning window. For any 
point at which the plan is found to be infeasible, the APC will determine which of the load profiles 
are in conflict and inform the MM. The planning process will iterate until the MM and APC have 
converged on a satisfactory plan. 

5. Decision ( Re-plan or Implement)'. Finally, the MM either commands the APC to implement the 
negotiated plan at the appropriate start time, or informs the APC of its intention to develop a new 
plan. The MM can ask the APC to implement any plan, regardless of feasibility; however, if the APC 
is tasked with implementing an infeasible load plan, load will be shed to force the system to remain 
within operational constraints. 
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3.1.2 Asynchronous Communications Cycle 

Note that the communication necessary to handle these events is inherently unplanned. 

1. Inform of Disturbance: Upon detection of a disturbance, the APC will determine the impact of the 
disturbance on its capability to operate as specified during the currently executing plan. This 
information, which is key to determining if a replan is necessary in order to maximize the vehicle’s 
mission objectives, is passed to the MM. 

2. Decision ( Re-Plan or Implement)’. The MM then decides whether a replan is necessary. If so, the 
planning process is started via a Planning Communications Cycle, with the disturbance accounted for 
as a new constraint. 

3.2 Paper Simulation 

The initial development of communication messages between the MM and the APC was 
accomplished using “paper simulations.” These paper sims utilized spreadsheets to generate messages, 
and email to transmit them between the MM (being developed at NASA Ames Research Center, in 
California) and the APC (being developed at NASA Glenn Research Center, in Ohio). In this manner, a 
number of complete planning sessions (Planning Communications Cycles) and disturbance identification 
and rectification sessions (Asynchronous Communications Cycles) were completed. This approach was 
taken to accomplish two goals: to accelerate communication message development, and to allow quick 
refinement of the relevant message content. 

At the time of the message format development, only prototype versions of the MM and the APC 
existed. These prototypes performed the relevant functions of the respective subsystems, but they were 
not yet automated — they only worked with a human in the loop. One obvious advantage of the paper sim 
approach was speed: by initiating paper simulations early on, the teams did not have to wait until 
automation of MM and APC functions was complete, thus accelerating development. Additionally, the 
messages developed during the paper sim drove the requirements of the automated software algorithms. 

Since entire Planning and Asynchronous Communication cycles were rapidly completed via the paper 
sims, lessons about which message content is relevant and which is superfluous were quickly learned. Use 
of spreadsheets, with easily variable content and format, along with email and phone communication 
between development teams allowed rapid evolution of message content, allowing messages to quickly be 
reduced to a thorough, yet efficient, format. This refinement allowed many details of the message content 
to be finalized early in the development cycle, where changes and updates are least expensive in terms of 
effort and schedule. 

3.2.1 Test Cases 

Throughout the paper sim, planning simulations were conducted under a variety of test conditions, in 
order to verify that the messages under development contained the necessary format and content to 
achieve the desired goals under any reasonable set of conditions. 

During Planning Communications development, sims were performed under a number of power 
system constraints: with imposed battery state of charge (SOC) limits, solar array (photovoltaic, or PV) 
output limits, PDU current output (single or multiple) limits, battery current limits, and line current limits. 

Disturbances introduced during development of Asynchronous Communications included unexpected 
load operation (loads on longer or shorter than expected, with varied impacts on the existing Plan), loads 
drawing less power than planned, and sources providing less power than planned. 

The details of the paper sim testing conditions are summarized in Table 1. 
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TABLE L— PAPER SIM COMMUNICATION TESTING CONDITIONS 


Planning 

Test 

Implementation 

Sim Tested 

Details 

1 

Battery SOC within limits 

Sim #1 - 13 

Constraint captured by peak power availability 
& energy availability 

2 

PV Output < limit 

Sim #1- 13 

Constraint captured by power availability 

3 

Limit one PDU power 

Sim #3 

Limit PDU 5 to 2kW 

4 

Limit multiple PDUs 

Sim #4 

PDU 1-4 limited to 425W switchable global 

5 

Limit line current 

Sim #6 

Limit line current from SA 1 

6 

Limit battery current 

Sim #5 

Limit Batteries to 83 A (lOkW, down from 
133A/32kW). Battery 1 global, battery 2 
tempo ra ry. 

7 

Temporary PDU power constraint 

Sim #4 

PDU 7 limited for 1 interval 


Asynch 

Test 

Implementation 

Sim Tested 

Details 

1 

Load on for too long - no impact 
in planning period 

Sim #8 

Load 13 on beyond scheduled period - should 
have turned off at 4:30 

2 

Load on for too long - impact 
during planning period 

Sim #11 

Load 12 remained on beyond scheduled period - 
should have turned off at 2:30 

3 

Load on for too short 

Sim #9 

Load 5 off 30 mins early 

4 

Load on for too short - additional 
power available significant, thus 
opportunity 

Sim #13 

Loads 12 and 14 turned off early (expected 
them to be on until 2:30) 

5 

Actual load < est load - additional 
power available insignificant 

Sim #10 

Load 26 drawing less power than planned 
(expected 700W, drawing 550W) 

6 

PV array output < est output - 
requiring replan 

Sim #12 

Output from Solar Array 1 lower than expected 


TABLE 2.— DETAILS OF PI COMMUNICATION 


PI #12 26-Mar- 14 


start time 

end time 

delta T (min) 

12:00 

10:30 

30 


3.2.2 Planning Communications Cycle 

During the course of the paper simulations, five messages were developed for a typical planning 
session. These are designated PI through P5. 

3.2.2.1 Initiate Planning (PI) 

The PI is initiated by the MM to start the planning process. Along with a header defining the message 
type, simulation number, and date (typical of all paper simulation communications), the PI specifies the 
planning horizon: start time, end time, and time step (delta T). It is important to note that the delta T used 
in the planning process is dependent upon both vehicle and power system time scales of interest, 
particularly eclipse/insolation periods. Details of the PI communication are shown in Table 2. 
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3.2.2.2 Define Power Constraints (P2) 

The P2 is the APC’s response to a PI message from the MM. In addition to the header, the P2 
contains nominal and peak power available for each time step in the planning window, as well as peak 
energy available to the MM during the course of the planning window. Also, any known constraints 
(temporary or global) on the system are also communicated. Constraints are formulated as the sum of 
loads must not exceed some power level. All power system constraints considered in the paper 
simulations are able to be constructed in such a manner. Note that this approach requires that both 
systems have common understanding of loads and load IDs. A distinction is made between “local” 
constraints, those active only during some planning intervals, and “global” constraints, those active during 
all intervals in the current planning window. 

Nominal power is the amount of power available given that the storage devices in the system are 
charging at a constant rate for the entire insolation period. During eclipse periods, the nominal power is 
the amount of power that the storage devices can supply to the system for the entirety of the eclipse 
without exceeding state-of-charge requirements. The Peak power considers that all generation devices are 
outputting at maximum for the time period. Thus, imbedded in this number are device power output 
constraints as well as each generator’s time-varying capability. 

If the power utilization (as defined by the load profile) is greater than the nominal power available, 
then the storage devices will be used to meet the excess load requirements. The result of this is that the 
storage cannot be charged and/or will deviate from the nominal state-of-charge range. To allow the MM 
to wisely use this capability, the total energy availability of the storage devices is given by the APC (in 
Watt-hours). The MM is then responsible for tracking the amount of peak power utilized as well as the 
duration used; the sum of the peak energy used for all time periods must be less than the peak energy 
available as provided by the APC. Details of the P2 communication are presented in Table 3. 

3.2.2.3 Define Load Schedule (P3) 

The P3, initiated by the MM in response to the P2, contains the proposed load schedule, developed 
based on the provided power profile. In addition to the header, the message contains a load status and 
priority for every load at each time step in the planning period. 

For this study, all loads are either “off’ or “on” (both systems have shared info as to how much power 
each load uses when on and off). Thus, both the state and priority of each load can be encoded in a single 
value, either “off’ or a priority number. Here, the lower the priority number, the higher the priority of the 
load. Details of the P3 communication are presented in Table 4. 


TABLE 3.— DETAILS OF P2 COMMUNICATION 


P2 #12 26-Mar-2014 


time 

Pnom (W) 

Ppeak (W) 

constraints 

12:00 

6008 

45968 


12:30 

6008 

45968 






3:30 

6008 

45968 


4:00 

5984 

21968 

loads 4,8,25,27,29 combined must not 
exceed 60W 





5:30 

5984 

21968 

loads 4,8,25,27,29 combined must not 
exceed 60W 

6:00 

6008 

45968 






9:30 

6008 

45968 


10:00 

5984 

21968 


peak energy avail 
(Wh) 

8000 






Global Constraint: Loads 1, 19 and 23 
combined must not exceed 360 W 
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TABLE 4.— DETAILS OF P3 COMMUNICATION 

P3 #12 26-Mar-2014 



12:00:00 AM 

12:30:00 AM 


10:00:00 AM 

load 

Priority 

Priority 


Priority 

1 

off 

off 


off 

2 

off 

12 


off 

3 

off 

off 


off 






29 

41 

41 


off 

30 

off 

off 


22 


TABLE 5.— DETAILS OF P4 COMMUNICATION 


P4 #9 18-Mar-2014 


time 

status 

12:00 

able to meet 



9:30 

Loads 1 , 4, and 9 must not 
exceed 500W 

10:00 

able to meet 


TABLE 6.— DETAILS OF P5 COMMUNICATION 

P5 #12 26-Mar-2014 

"Implement Plan" 


3.2.2.4 Determine Feasibility (P4) 

The P4, initiated by the APC in response to the P3, determines feasibility of meeting the proposed 
load schedule. In addition to the header, the P4 contains a status at each time step of the planning period, 
communicating whether or not the power system can meet the load schedule. If the system cannot meet 
the proposed schedule, the message describes the nature of the conflict. Again, any constraint will be 
formulated as the sum of loads must be less than some power level. Details of the P4 communication are 
presented in Table 5. 

3.2.2.5 Re-Plan or Implement (P5) 

The P5 message, initiated by the MM, commands the APC to implement the proposed plan in the event 
that the P4 stated “able to meet’ at all-time steps. Otherwise the MM will rework the schedule, which is 
done by recalculating, then sending out a new P3. Details of the P5 communication are presented in Table 6. 
An “Implement Plan” P5 message concludes a successful planning session. 

3.2.3 Asynchronous Communications Cycle 

Two different asynchronous messages were developed during the course of the paper simulations: the 
A1 and the A2. 

3.2.3.1 Inform of Disturbance (Al) 

The Al message is initiated by the APC in the event of a disturbance to the power system or a 
deviation in the system that impacts a parameter used during load planning. In addition to the header, it 
contains the time of occurrence, the nature of the disturbance, and the impact on the schedule. Schedule 
impact is described by the time, within the planning window, at which the disturbance will prevent the 
power system from meeting the negotiated schedule. If the disturbance causes no impact to the schedule, 
no time is provided. Details of the Al communication are presented in Table 7. 
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TABLE 7.— DETAILS OF A1 COMMUNICATION 


Al #12 26-Mar-2014 

Time 

Disturbance 

Impact 

3:05 

Output from Solar Array 1 lower 
than expected 

"No impact within planning period" or "Will exceed peak 
power allotment by 3:27" 


TABLE 8.— DETAILS OF A2 COMMUNICATION 

A2 #12 26-Mar-2014 

"Replan Required" or "No Action Required" 


3.2.3.2 Re-Plan or Implement (A2) 

The A2 message is initiated by the MM in response to an Al. In addition to the header, the A2 
communicates response to the disturbance: “No Action Required”, or “Replan Required”. Details of the 
A2 communication are presented in Table 8. 

3.3 Automated Communications Format 

The final step in the development of the communication format was to convert each message into a 
computer readable format, to enable these messages to be sent and processed by automated software. 

Since we were not overly concerned with message bandwidth at this early development stage, a bit-level 
encoding was not necessary. Additionally, coding the messages as character arrays allows them to be 
processed by software, while maintaining human readability, which will be helpful during testing. 

The protocol over which the messages are to be sent is not particularly important at this time, and thus 
TCP sockets are used. Whitespace and line breaks included in the messages shown below are simply for 
human readability and are stripped from both incoming and outgoing messages. 

Note that the messages use a 24 hr clock; thus use leading zero if applicable (hh:mm). Also, text is 
not case-sensitive for the receiver, but is standardized for the automated sender: capitalize first word only. 

Pseudo-code describing the decision logic for message handling, from the MM and the APC 
perspective, is provided below. 

1. MM Message Handling Pseudo-code : 

If START 

then send PI message 
else if receive P2 message 

then send P3 message 
else if receive P4 message 

then if P4 message has no violations 

then send P5 message (Implement) 

else resend P3 with the new constraints from P4 taken into account 

2. APC Message Handling Pseudo-code : 

If receive PI message 

then send P2 message 
else if receive P3 message 

then send P4 message 
else if receive P5 message 
then Implement 

Details of the developed Automated Communications Format messages, for the Planning and 
Asynchronous Communications, are included in the following sections. 
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3.3.1 Planning Communications Cycle 

Automated formats for the five messages comprising a typical Planning Communications session are 
described below. 

3.3.1. 1 Initiate Planning (PI) 

Time recording is based on the ISO-8601 standard. All times are UTC. Since we’ve decided the 
minute is our lowest resolution, no seconds are required. It is assumed that the planning horizon is limited 
to 24 hr, to prevent ambiguity. Note that the “final time” is defined as the end of the Planning period, not 
as the beginning of the last interval. Thus if the planning period was defined as 01:00 to 02:00 with a step 
of 30 min, there would be two steps in the period; one from 01:00 to 01:30, and one from 01:30 to 02:00. 
Details of the automated PI message are presented in Table 9. 

3.3. 1.2 Define Power Constraints (P2) 

Constraints are formatted as The sum of load power consumption must be less than some value in 
watts’. To encode this, each of the load power consumption values is replaced by the load ID# to produce: 
“4+8+25<60” which is read as the sum of the power used by loads 4, 8, and 25 must be less than 60W. 
The “+” signs are markers between each of the load IDs, and the “<” sign is the demarcation of the load 
IDs from the power limit. If multiple local constraints (constraints limited to a subset of the planning 
window) exist at a single time step, they will be separated by commas. If multiple global constraints exist, 
they will be listed on separate lines. Details of the automated P2 message are presented in Table 10. 

3.3. 1.3 Define Load Schedule (P3) 

Note that 0 is a valid priority, and is the highest priority possible, so use of a “0” to indicate the load 
is in the “off’ state is not practical. Thus loads in the off state are designated by just a comma. Details of 
the automated P3 are presented in Table 11. 

3.3. 1.4 Determine Feasibility (P4) 

Will send content only for violation time steps. Details of the automated P4 message are presented in 
Table 12. 

3.3.1.5 Decision: Re-Plan or Implement (P5) 

The MM will simply send an “Implement” command. Another option is to command “save with a 
name”, but that feature will not be implemented for this simulation. Details of the automated P5 message 
are presented in Table 13. 


TABLE 9.— DETAILS OF PI COMMUNICATION 


Message 

Format 

Example 

PI 

Format: 

initial time, final time, delta t (minutes); 

<P1> 

2014-04-01T12:00, 2014-04-01T19:30, 30; 
</Pl> 


TABLE 10.— DETAILS OF P2 COMMUNICATION 


Message 

Format 

Example 

P2 

T (hh:mm), Pnom, Ppeak, Constraint; 

Wh, peak energy available; 
global constraint; 

<P2> 

12:00, 6008, 45968,; 

14:00, 6008, 45968, 4+8+25+27+29<60; 

Wh, 8000; 

3+7+26+28<1500; 

</P2> 
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TABLE 11.— DETAILS OF P3 COMMUNICATION 


Message 

Format 

Example 

P3 

, TO, Tl, ..., Tn; 

Load #, time interval 1 priority, . . ., time interval 
n priority; 

<P3> 

, 12:00, 12:30, . . ., 19:00; 

1.. ...., 14, 18,...,; 

2. , 24, . . ., , 48, . . ., ; 

30., 18,... ,21,,; 

</P3> 


TABLE 12.— DETAILS OF P4 COMMUNICATION 


Message 

Format 

Example 

P4 

Time (hh:mm), new constraint; 

<P4> 

18:30, 3+4+5+6<60; 
</P4> 


TABLE 13.— DETAILS OF P5 COMMUNICATION 


Message 

Format 

Example 



<P5> 

P5 

Implement; 

Implement; 



</P5> 


TABLE 14.— DETAILS OF A1 COMMUNICATION 


Message 

Format 

Example 

Al 

Format: 

Timestamp, disturbance, impact horizon; 

<A1> 

15:03, There was a disturbance,; 

14:35, There was a disturbance, 14:53; 
</Al> 


TABLE 15.— DETAILS OF A2 COMMUNICATION 


Message 

Format 

Example 


Format: 
No action; 

<A2> 


A2 

No action; 
</A2> 



3.3.2 Automated Asynchronous Communications Cycle 

Automated formats for the two messages comprising a typical Asynchronous Communications 
session are described below. 

3.3.2.1 Inform of Disturbance (Al) 

In the event of a disturbance, the Al is sent from the APC to the MM. Details of the automated Al 
message are shown in Table 14. 

3.3.2.2 Decision: Re-Plan or Implement (A2) 

Details of the automated A2 message are presented in Table 15. 
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4.0 Conclusions 


This paper describes the development of a communication scheme between two key systems in an 
autonomous control system for a manned deep space vehicle. The focus of the effort is the electrical 
power subsystem. A nominal spacecraft power system architecture was described, and prototype versions 
of these two key systems, the Mission Manager (MM) and Automated Power Controller (APC), were 
constructed. 

To develop the communication messages, first a set of rapid-prototyping “paper” simulations were 
run, simulating communication between the MM and the APC under a variety of operational conditions. 
These paper sims enabled development of message content and format necessary to achieve the desired 
goals: negotiation of a load schedule that meets the global vehicle and local power system requirements, 
while enabling communication of off-plan disturbances that arise while executing a negotiated plan. Once 
these messages were optimized, and shown to perform well under nominal and off-nominal conditions, 
they were codified for computer communication, for use in automated testing. A summary of the 
communication formats developed in this paper is included in the Appendix. 

Future work in this area includes the addition of more complex disturbances, such as failures, and 
testing on a hardware system. 
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Table 1 6, Summ ary of the Autom ated Communication Format b etween t he MM and AFC to develop a loa d sch edule. 


Appendix — Summary of Automated Communication Formats 

A summary of the Automated Communication Formats for Planning and Asynchronous 
communication is included in Tables 16 and 17. 
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